FPGA devices are becoming denser everyday. However, processing device technology is not keeping pace with the need for compiling Very High Speed Integrated Circuit (VHSIC) Hardware Description Language (VHDL) files into a bit file for loading onto today's increasingly dense FPGAs. Partial reconfiguration is a technique that enables the reconfiguration of FPGA hardware without requiring a reset. By providing a FPGA with reconfigurable blocks or modules, it enables the FPGA to continue processing during reconfiguration without interruptions, i.e., part of the FPGA may be reprogrammed with a new function while the remainder of the device continues to run. This allows hardware designs to have dynamically changing components, allowing FPGA resources to be efficiently allocated as processing needs change. However, prior attempts to support partial reconfiguration are awkward to implement and require a dedicated mapping of the individual module to the FPGA device, severely limiting modularity and replacement options. Special tools are required to accomplish these prior designs and I/O mapping limitations limit the distribution of clocks and other critical shared signals, thus requiring each newly reconfigured module to have the same I/O map and I/O functionality as the previous configuration.
FIG. 1 is a block diagram of a conventional partial reconfiguration communication architecture for a FPGA 100 according to the prior art. As shown in FIG. 1, multiple partial reconfiguration (“PR”) blocks 102a-102e are provided and coupled together by bus macros 104. A separate bus macro 104 is required to connect each pair of PR blocks 102, and each given PR block 102 is limited by its bus macro connections to a particular and fixed interconnection position relative to the other PR blocks 102. Multiple bus macros 104 are therefore required per PR block 102. Using the conventional configuration architecture of FIG. 1, the number of bus macros 104 necessary multiplies with the addition of more partial reconfiguration blocks 102. In this regard, bus macros 104 are inefficient in that they can only handle 4 bits per instantiation. Moreover, each type of PR block (e.g., fast Fourier transform “FFT” block or finite impulse response filter “FIR” functionality block) requires a customized interface particular to its given functionality for connection to a corresponding customized bus macro interface.